本篇是故事一的「理解」篇。

本篇要回答：為什麼「要用 Socket、Streaming 還是 MQTT」這個問題本身就有問題？技術選型的決策構面應該長什麼樣子？

當時發生了什麼

專案討論走到「判定結果要如何送往後段設備」時，桌上出現了一張很自然的選單：要用 Socket、Streaming，還是 MQTT？三選一。這種把不同抽象層的名詞排成同一張選單的問法，在實際工作裡出現的頻率高得驚人。

這張選單看起來像三個平行選項，實際上三個詞根本不在同一個抽象層。Socket 是作業系統提供的傳輸層通訊介面；MQTT 是應用層的訊息協定，走發布／訂閱（Publish/Subscribe）模式，通常還跑在 Socket 之上；Streaming 則更接近一種資料傳遞的形態描述，本身不指定協定。把它們放在同一題裡，就像問「今天要搭卡車、走冷鏈，還是用宅配」——卡車是交通工具，冷鏈是運送模式，宅配是物流機制，三者可以同時成立，也可以互相組合。

我原本怎麼判斷

當時的判斷方式是「名詞收集」：把聽過的、專案用過的、文章推薦的技術名稱排成清單，然後試著從中選出正確答案。背後的假設是：選型就是在既有名詞裡挑一個最好的。

這個假設的問題在於，名詞清單掩蓋了真正要回答的問題。清單上的每個名詞各自回答不同層次的問題，而場景條件一個都還沒確認——這其實是 Day 01 的失效模式換了一件衣服再出現一次：還沒定義結果，先開始挑工具。

名詞收集還有一個副作用：清單越長，越像做了功課，越沒有人敢問「所以我們到底要解決什麼」。

我怎麼查證或重現

破解這張選單的第一步不是回答它，而是先釐清各技術各自服務的場景：Socket 適合長時間連線、低延遲、頻繁雙向溝通的設備（例如廠內搬運設備的即時控制）；Streaming 適合連續產生、可分段傳輸、邊接收邊處理的資料（例如影像串流、系統 log）；MQTT 適合弱網環境下的小筆資料回報，發布端不需管理「誰來收、收不收」（例如遠端感測器）。再往上抽象成三個場景問題：資料如何回報（低頻率輪詢或高密度即時推送）？控制如何送達（強一致性或最終一致性）？斷線後如何恢復（自動重連或資料補償與同步）？

我做的查證是兩件事：回頭翻各技術的官方文件確認抽象層，然後把三個場景問題擴充成一張完整的決策構面表：

沿著這張表走一次就會發現：先回答完場景問題，名詞會自己就定位。例如判定結果若是「每工件一筆、不能遺失、後段設備要能離線補收」，那需要的是具備傳遞保證與離線緩衝的訊息機制，MQTT（搭配適當 QoS）成為候選是因為它符合這些條件，而不是因為它出現在選單上。

區分證據等級。已確認事實：三個名詞的抽象層定義（可查閱各官方文件）。合理推論：三選一問法反映的是名詞收集式選型。示意內容：上述各技術的場景舉例與「每工件一筆」的例子。

今天留下什麼方法

留下那張決策構面表、一句自我提醒——工程師的價值，在於把技術限制轉化為決策路徑——以及一個選型前的排序原則：

先把場景與限制整理成一條決策路徑，再讓技術名詞來應徵，而不是先押一個名詞，再回頭替它找理由。

本篇結論：

技術名詞不是答案清單；工程判斷要先把場景與限制整理成一條決策路徑。

下一篇（Day 05）把故事一收攏：如果結果沒有先被定義，所有技術細節都只是在替空白需求單上色——並交出第一份可重用模板。